Some embodiments of the present disclosure are directed to an improved approach for implementing database software upgrades using a specify-validate-execute protocol.
Databases comprise the actual storage on a physical storage device (e.g., a disk drive), which works in combination with corresponding software. In exemplary scenarios, a database comprises tables and records that are laid out in an ordered sequence of bytes. A software application that accesses the physical data on the storage device has a template of the layout, and can retrieve information from certain portions or fields in the data.
In some situations, for example as time passes, the layout of the data needs to be modified. An example of such a situation was the occurrence of the millennium, when the (formerly) accepted way of storing a date code was to use just two digits (i.e., referring to the number of year “after 1900”). As we approached the turn of the millennium to the year 2000, it became apparent that data stored in the two-digit (or equivalent) format would become ambiguous. That is, would the two digits “01” refer to “1901” or would it refer to “2001”. The storage of the year data needed to change, as did the software (e.g., application software) that accessed the stored data.
A simple approach to upgrading this sort of configuration required following a procedure to take the primary database “down”, then upgrade the software, then rebuild the primary database, then bring the primary database “back online”. There are many limitations to this approach, for example:                Unavailability of the Databases: The primary database and any of its backups become unavailable for the period of upgrade (often several hours or more).        All-or-Nothing Impact of Unforeseen Defects Related to the New Software: Upgrades often cause changes in application behavior because the underlying software has changed. By upgrading the primary database in its entirety, that is, in an all-or-nothing manner, the database is susceptible to unintended operation such as might occur as a result of unforeseen software defects. Even when the probability of encountering such defects may be low, the effect can be catastrophic on database availability and/or loss of data.        Other limitations.        
A better way is needed. The aforementioned technologies do not have the capabilities to perform database software upgrades while minimizing (or eliminating) downtime, and mitigating the effects of errors that might occur in the transitions to the upgraded database format and database software. Therefore, there is a need for an improved approach.